建立好雲端環境之後，下一個很自然的問題就是：「資料要放在哪裡？」

Cloud Storage 是 Object Storage，不應該直接把它理解成「網路硬碟」。它主要透過 API 操作資料，使用 Bucket 作為容器，再用 Object 儲存實際內容。每個 Object 都具有名稱、內容、metadata 與相關權限，因此它的概念和傳統作業系統中的資料夾、檔案並不完全相同。對資料工程來說，Cloud Storage 更重要的角色，是作為大量非結構化或半結構化資料，以及資料湖的入口。

理解 Object Storage 後，就可以開始思考不同儲存方式的差異。Object Storage 適合資料湖、備份與媒體檔案；Block Storage 則比較接近 VM 使用的磁碟，適合作業系統與需要檔案系統的應用；File Storage 則提供共享目錄與檔案語意，適合既有應用程式或多台主機共同存取。因此，選擇 Storage 不能只問「哪一個比較便宜」，而應該比較存取介面、延遲、吞吐量、一致性、共享方式與成本。

Cloud Storage 中另一個重要概念是 Storage Class。教材介紹 Standard、Nearline、Coldline 與 Archive。直覺上，越冷的資料每 GB 儲存價格可能越低，但不能因此把所有資料都丟進 Archive。例如每天都要讀取的訓練資料，如果使用低頻儲存類別，可能因資料取回費用與最低儲存時間而得不償失。因此真正的選型方式，是先了解資料的讀取頻率與保留時間，再決定 Storage Class，而不是單純比較每 GB 的價格。

建立 Bucket 時，特別要求注意名稱、Region、Storage Class、公開存取防護與 Uniform Access 等設定。例如 Bucket 名稱必須在全球命名空間中唯一，因此名稱衝突並不代表權限設定錯誤；而 Bucket 的位置建立後也不是一般欄位，可以隨意修改，因此建立前就應該先確認資料位置。

上傳成功，不等於資料正確。

因為「檔案存在」和「檔案正確」其實是兩件事情。假設不小心把舊版本資料上傳到 Bucket，Console 仍然可能顯示上傳成功。如果只看到綠色的成功訊息，我們根本不知道內容是不是自己真正需要的版本。因此把驗收分成存在、結構、內容與可追溯性幾個層次，並要求記錄來源、上傳時間、命令、Project ID 與操作者。

這裡也延伸出 checksum 的概念。我們可以分別計算本機檔案與 Cloud Storage Object 的 MD5，再確認兩者是否一致。不過 MD5 的用途在這裡只是確認內容完整性，並不能證明檔案來源可信，更不能把它當成密碼安全機制。若要驗證身分與防止惡意竄改，就需要更適合的數位簽章與金鑰機制。

最後，Cloud Storage 還會接觸資料湖的概念。資料湖不是單純「把所有檔案丟進 Bucket」，而是可以透過不同的資料區域（zones）來管理資料。例如 Google Cloud 的 Knowledge Catalog 支援 Raw zone 與 Curated zone，分別用於存放需要進一步處理的原始資料，以及已整理、適合分析與使用的資料。